Industrial controllers are special purpose processing devices used for controlling industrial processes, machines, manufacturing equipment, and other factory automation applications. In accordance with a control program or routine, an industrial controller can measure one or more process variables or inputs representative of the status of a controlled process, and change outputs effecting control of the process. The inputs and outputs can be binary, (e.g., on or off), and/or analog assuming a continuous range of values. The control routine can be executed in a series of execution cycles with batch processing capabilities, and can comprise one or more functional units. Such a control routine can be created in a controller configuration system having tools and interfaces whereby a user can implement a control strategy using programming languages or graphical representations of control functionality. The control routine can be downloaded from the configuration system into one or more controllers for implementation of the control strategy in controlling a process or machine.
The measured inputs received from a controlled process and the outputs transmitted to the process can pass through one or more input/output (I/O) modules in a control system, which serve as an electrical interface between the controller and the controlled process, and can be located proximate or remote from the controller. The inputs and outputs can be recorded in an I/O table in processor memory. Input values can be asynchronously read from the controlled process by one or more input modules and output values can be written directly to the I/O table by a processor for subsequent communication to the process by specialized communications circuitry. An output module can interface directly with a controlled process by providing an output from an I/O table to an actuator such as a motor, drive, valve, solenoid, and the like.
During execution of the control routine, values of the inputs and outputs exchanged with the controlled process pass through the I/O table. The values of inputs in the I/O table can be asynchronously updated from the controlled process by dedicated scanning circuitry. This scanning circuitry can communicate with input and/or output modules over a bus on a backplane or network communications. The scanning circuitry can also asynchronously write values of the outputs in the I/O table to the controlled process. The output values from the I/O table can be communicated to one or more output modules for interfacing with the process. Thus, a controller can simply access the I/O table rather than needing to communicate directly with the controlled process.
In distributed control systems, separating the industrial controller into a number of control modules (each of which performs a different function) can facilitate controller hardware configuration. Particular control modules needed for the control task can then be connected together on a common backplane within a rack and/or through a network or other communications medium. The control modules can include processors, power supplies, network communication modules, and I/O modules exchanging input and output signals directly with the controlled process. Data can be exchanged between modules using a backplane communications bus, which can be serial or parallel, or via a network. In addition to performing I/O operations based solely on network communications, smart modules exist which can execute autonomous logical or other control programs or routines.
Various control modules of a distributed industrial control system can be spatially distributed along a common communication link in several racks. Certain I/O modules can thus be located proximate a portion of the control equipment and away from the remainder of the controller. Data can be communicated with these remote modules over a common communication link, or network, wherein all modules on the network communicate via a standard communications protocol.
In a typical distributed control system, one or more I/O modules are provided for interfacing with a process. The outputs derive their control or output values in the form of a message from a master or peer device over a network or a backplane. For example, an output module can receive an output value from a processor, such as a programmable logic controller (PLC), via a communications network or a backplane communications bus. The desired output value is generally sent to the output module in a message, such as an I/O message. The output module receiving such a message will provide a corresponding output (analog or digital) to the controlled process. Input modules measure a value of a process variable and report the input values to a master or peer device over a network or backplane. The input values can be used by a processor (e.g., a PLC) for performing control computations.
Data and behavior are separate in today's automation systems wherein copies of data can exist at multiple levels in a control architecture, such as the plant floor, control level and MES level. Maintaining persistence at multiple locations in the control system for a particular data source, for example, can lead to several problems. For instance, data can be changed independent of system behavior which can lead to inconsistencies between the data and behavior. In addition, data and/or behavior can be changed at one level (e.g., control level) without making corresponding changes at other levels (e.g., MES level) that can surface as incorrect automation system behavior.
Furthermore, as noted, data is typically stored in one or more controllers within a particular control system. Data can be stored in multiple formats including various bit, word and integer values which can be distributed throughout a system and thus not collected or organized, which can provide difficult and cumbersome communication with an external device. In order to communicate with the data, generic I/O reads can be employed to read data in disparate locations in order to determine the attributes and methods of such data and how such data can be employed. In this manner, data can be stored at various levels in the architecture and may not be self-describing and therefore cannot be easily utilized by disparate levels in the architecture.
Conventionally, the format and meaning of data must be predefined such that the format and value of data (e.g., bit, word, tag name, etc.) has designated meaning to the control system. For example, if a word “Joe” represents a scaling factor, such meaning behind the data has to be conveyed from the source to the subscriber, layer by layer within a control system (e.g., from a component to the MES layer) so the data can be read and understood by the data subscriber. Similarly, communication in the opposite direction encounters difficulty such that if you want to perform a procedure, you have to follow a specific protocol to make changes to data. Thus, conventional communication between the control system and the MES layer, for example, can fail if a particular data communication protocol is not followed.
FIG. 13 is provided to illustrate one particular industrial automation architecture, wherein such figure and accompanying text are provided to illustrate various deficiencies associated with conventional architectures. The current state of the art in industrial automation systems employs a hierarchical architecture with two or more layers. Prior art FIG. 13 illustrates a typical, 3-layer architecture that utilizes a control layer 1310, a Manufacturing Execution (MES) System 1320 layer and an Enterprise Resource Planning (ERP) 1330 layer. It is important to note the functions in the layered architecture. The control layer 1310 (e.g., factory floor) can contain controllers such as PLCs and drives, which are specialized for real-time control. As such, these controllers capture factory floor data and communicate this data to a higher level (e.g., MES layer 1320, ERP layer 1330, etc.). The MES layer 1320 can be comprised of one or more computing devices with structured data, software applications and transaction-oriented architecture. The ERP layer 1330 can employ one or more computing devices that typically run ERP software such as order management and customer management applications, for example. The control layer 1310 data comprises the state of sensors and actuators and does not relate these states to physical or logical entities such as a batch of product or efficiency of a machine. Such data is called unstructured, since significant custom programming is required to translate this data to a structured data type that is typically utilized at the MES layer 1320 or the ERP layer 1330. Also, due to the controllers passing unstructured data to multiple MES applications that may reside on multiple computers, it is common today to have many copies of the same data in several places. This is undesirable due to reasons such as difficulty in system recovery and discovery of a single “correct” copy of the data in the event of a failure.
Accordingly, in view of at least the above, flexible and forgiving systems and methods to communicate data and behavior within a control architecture are needed in the art of industrial automation.